GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Review (Softwaretest)</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Review (Softwaretest)</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>In einem <b>Review</b> werden Arbeitsergebnisse der <a href="Softwaretechnik" title="Softwaretechnik">Softwareentwicklung</a> manuell geprüft. Jedes Arbeitsergebnis kann einer Durchsicht durch eine andere Person unterzogen werden. Der oder das Review ist eine <a href="Statisches_Software-Testverfahren" title="Statisches Software-Testverfahren">statische Testmethode</a> und gehört in die Kategorie der analytischen Qualitätssicherungsmaßnahmen.

</p><p>In Anlehnung an die Norm <a href="Software_Quality_Assurance_Plan" title="Software Quality Assurance Plan">IEEE 730</a> ist das Review ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesem kommentiert oder genehmigt werden.

</p><p>Der untersuchte Gegenstand eines Reviews kann verschieden sein. Es wird vor allem zwischen einem <b>Code-Review</b> (<a href="Quelltext" title="Quelltext">Quelltext</a>) und einem <b>Architektur-Review</b> (<a href="Softwarearchitektur" title="Softwarearchitektur">Softwarearchitektur</a>, insbesondere Design-Dokumente) unterschieden. Diesen Bereichen zugeordnet sind technische Dokumente wie etwa <a href="Readme" title="Readme">Readmes</a>, Installationsanweisungen oder Bedienungsanleitungen, aber auch Programme oder Skripte, die für eine Installation gebraucht werden, sowie Dokumente mit Informationen und Anweisungen an andere, ähnlich qualifizierte Entwickler, um diese zu befähigen, den Übersetzungsvorgang der Quellen zu einem späteren Zeitpunkt erfolgreich zu reproduzieren, etwa für ein Bug-Fixing (Fehlerkorrektur) oder eine Weiterentwicklung.

</p><p>Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem oder mehreren Gutachtern Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Dabei kann der Gutachter selbst ein <a href="Softwareentwickler" title="Softwareentwickler">Softwareentwickler</a> sein. Für unerfahrene Entwickler bietet der Code-Review durch einen erfahrenen Entwickler eine gute Möglichkeit, sich schnell und praxisorientiert weiterzubilden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Nutzen_von_Reviews">Nutzen von Reviews</h2></div>

<p>Der Einsatz von Reviews führt zu einer deutlichen Reduktion von Fehlern. Laut Capers Jones’ Studien von ca. 12.000 Projekten führen Requirements Reviews zu einer Reduktion der zu erwartenden Fehler um 20 % bis 50 %, Top-level Design Reviews zwischen 30 % und 60 %, detaillierte funktionelle Design Reviews zwischen 30 % und 65 % und detaillierte logische Design Reviews zwischen 35 % und 75 %. Das entspricht in etwa der Effektivität von Systemtests (25 % bis 65 % aller Fehler).<sup id="cite_ref-Jones2002_1-0" class="reference"><a href="#cite_note-Jones2002-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> Laut Steve Mcconnel finden Design- und Code-Reviews ca. 60 % aller Fehler.<sup id="cite_ref-CodeComplete_2-0" class="reference"><a href="#cite_note-CodeComplete-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>Dabei laufen verschiedene Qualitätsprozesse ab:

</p>

<ul><li>Der Programmierer entdeckt selbst eine Verbesserungsmöglichkeit.</li>

<li>Der Rezensent stellt Verständnisfragen und der Programmierer kann den Code so verändern (beispielsweise durch geeignete Namensgebung oder <a href="Softwaredokumentation" title="Softwaredokumentation">Dokumentation</a>), dass diese Fragen beantwortet sind und so die Verständlichkeit verbessert wurde.</li>

<li>Der Rezensent entdeckt Verbesserungsmöglichkeiten und empfiehlt diese dem Programmierer.</li></ul>

<p>Zu den typischen Schwächen, die mit Reviews entdeckt werden können, gehören:

</p>

<ul><li>Abweichungen von <a href="Standard" title="Standard">Standards</a>, z. B. Verletzung von <a href="Namenskonvention_(Datenverarbeitung)" title="Namenskonvention (Datenverarbeitung)">Namenskonventionen</a></li>

<li>Fehler gegenüber (oder auch in) den <a href="Anforderung_(Informatik)" title="Anforderung (Informatik)">Anforderungen</a></li>

<li>Fehler im Design</li>

<li>Unzureichende <a href="Wartbarkeit" title="Wartbarkeit">Wartbarkeit</a></li>

<li>Falsche <a href="Spezifikation" title="Spezifikation">Schnittstellenspezifikation</a></li></ul>

<p>Resultate von Code-Reviews sind neben den damit gefundenen Fehlern eine verbesserte <a href="Codequalit%C3%A4t" title="Codequalität">Codequalität</a>. Diese wiederum verhindert zukünftige Fehler und steigert die <a href="Effizienz_(Informatik)" title="Effizienz (Informatik)">Effizienz</a>; <a href="Robustheit" title="Robustheit">Robustheit</a>; Wartbarkeit, z. B. durch verringerte <a href="Komplexit%C3%A4t_(Informatik)#Softwarekomplexität" title="Komplexität (Informatik)">Komplexität</a>. Darüber hinaus können Fehler, die im Review auffallen, häufig bedeutend kostengünstiger behoben werden, als wenn diese erst während der Testdurchführung gefunden werden.

Reviews und Inspections können die Softwareentstehungskosten um bis zu 30 % reduzieren.<sup id="cite_ref-Jones2002_1-1" class="reference"><a href="#cite_note-Jones2002-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Reviewprozess">Reviewprozess</h2></div>

<p>Ein typisches Review besteht aus folgenden Hauptphasen:

</p>

<dl><dt>Planung</dt>

<dd>

<ul><li>Auswahl der beteiligten Personen und Besetzung der Rollen</li>

<li>Festlegung der <a href="Vorbedingung_(Informatik)" title="Vorbedingung (Informatik)">Vor-</a> und <a href="Nachbedingung_(Informatik)" title="Nachbedingung (Informatik)">Nachbedingungen</a></li></ul></dd></dl>

<dd>

<ul><li>Verteilung der Dokumente</li>

<li>Erläuterung der Ziele und des Prozesses</li>

<li>Prüfung der Vorbedingungen</li></ul></dd></dl>

<dl><dt>Individuelle Vorbereitung</dt>

<dd>

<ul><li>Notierung von potentiellen Fehlern, Fragen und Kommentaren</li></ul></dd></dl>

<dl><dt>Reviewsitzung</dt>

<dd>

<ul><li>Diskussion und Protokollierung der Ergebnisse</li>

<li>Empfehlungen geben oder Entscheidungen über Fehler treffen</li></ul></dd></dl>

<dl><dt>Überarbeitung (rework)</dt>

<dd>

<ul><li>Beheben der gefundenen Fehler, typischerweise durch den Autor</li></ul></dd></dl>

<dl><dt>Nachbearbeitung (follow up)</dt>

<dd>

<ul><li>Überprüfung der Überarbeitung</li>

<li>Prüfung von Testende-Kriterien</li></ul></dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Reviewarten">Reviewarten</h2></div>

<p>Reviews variieren zwischen sehr informell (unstrukturiert) und sehr formal (d. h. tief strukturiert und geregelt). Die Art und Weise, wie ein Review durchgeführt wird, ist abhängig von den festgelegten Zielen des Reviews (z. B. dem Finden von Fehlern, dem Erwerb von Verständnis oder einer Diskussion mit Entscheidung durch <a href="Konsens" title="Konsens">Konsens</a>).

</p><p>Die Norm <a href="IEEE_1028" class="mw-redirect" title="IEEE 1028">IEEE 1028</a> unterscheidet die folgenden Reviewarten:<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p>

<dl><dt>Technisches Review</dt>

<dd>

<ul><li>Fachliche Prüfung eines wesentlichen Dokumentes (z. B. <a href="Softwarearchitektur" title="Softwarearchitektur">Architekturentwurf</a>) auf Übereinstimmung mit der Spezifikation</li>

<li>Zweck: Diskussion, Entscheidungen treffen, Alternativen bewerten, Fehler finden, technische Probleme lösen</li></ul></dd></dl>

<dl><dt>Informelles Review</dt>

<dd>

<ul><li>Entspricht inhaltlich dem technischen Review, es soll ihm gegenüber aber Zeit gespart werden und daher wird es als nicht formaler Prozess durchgeführt.</li>

<li>Das informelle Review ist nicht im IEEE-Standard für Software Reviews enthalten.</li>

<li>Eine strukturierte Protokollierung/Dokumentierung ist möglich. Ein Bericht wird in der Praxis meist nur in einer einfacheren Form erstellt oder teils ganz ausgelassen.</li>

<li>Es ist eine einfache Art eines Reviews, bei dem meistens „Gegenlesen unter Kollegen“ durchgeführt wird.</li>

<li>Inhaltlich können dieser Art folgende, praxisbezogene Review-Arten zugeordnet werden (Begriffe je nach <a href="Firmenkultur" class="mw-redirect" title="Firmenkultur">Firmenkultur</a> unterschiedlich):

<ul><li><a href="Schreibtischtest" title="Schreibtischtest">Schreibtischtest</a> (Programm-Autor spielt den Code anhand von einfachen <a href="Testfall" title="Testfall">Testfällen</a> gedanklich durch.)</li>

<li><a href="Peer_review#Qualitätssicherung_in_Unternehmen" class="mw-redirect" title="Peer review">Peer Rating</a> (Gutachten, das von gleichgestellten Programmierern anonym über ein Programm erstellt wird.)</li>

<li>Stellungnahmeverfahren (Autor verteilt Arbeitsergebnis an ausgewählte Gutachter zur Beurteilung.)</li></ul></li></ul></dd></dl>

<dl><dt><a href="Code-Walkthrough" title="Code-Walkthrough">Walkthrough</a></dt>

<dd>

<ul><li>Diskussion von Szenarien, Probeläufen und Alternativen im Kreis gleichgestellter Mitarbeiter mit möglichst niedrig gehaltenem Aufwand</li>

<li>Zweck: Lernen, Verständnis erzielen und Fehler finden</li></ul></dd></dl>

<dl><dt><a href="Inspektion_(Software-Entwicklung)" title="Inspektion (Software-Entwicklung)">Inspektion</a></dt>

<dd>

<ul><li>Formalste Reviewtechnik mit einem dokumentierten Vorgehen nach <a href="IEEE_1028" class="mw-redirect" title="IEEE 1028">IEEE 1028</a>.</li>

<li>Zweck: Sichtüberprüfung von Dokumenten, um Mängel zu finden (z. B. Nichteinhaltung von Entwicklungsstandards, Nicht-Konformität gegenüber <a href="Spezifikation" title="Spezifikation">Spezifikationen</a> usw.).</li></ul></dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Erfolgsfaktoren">Erfolgsfaktoren</h2></div>

<p>Damit Reviews erfolgreich durchgeführt werden, müssen verschiedene Bedingungen erfüllt sein:

</p>

<ul><li>Definition von klaren Zielen</li>

<li>Auswahl von geeigneten Personen</li>

<li>Konstruktive Kritikfähigkeit (gefundene Fehler werden objektiv zur Sprache gebracht und positiv aufgenommen)</li>

<li>Psychologische Aspekte (insbesondere Sicherstellung einer positiven Erfahrung für den Autor)</li>

<li>Auswahl der geeigneten Reviewtechnik</li>

<li>Unterstützung des Reviewprozesses durch das Management</li>

<li>Existenz einer Kultur von Lernen und Prozessverbesserung</li></ul>

<p>Anforderungen an Rezensenten:

</p>

<ul><li>Er darf den Code nicht selbst geschrieben haben.</li>

<li>Er muss <a href="Taktgef%C3%BChl" title="Taktgefühl">Taktgefühl</a> haben: Codereviews können für den Programmierer unangenehm sein, da er den Eindruck bekommen könnte, der eigene Code werde <a href="Kritik" title="Kritik">kritisiert</a>. Wenn der Rezensent nicht taktvoll vorgeht, wird Widerstand und Ablehnung gegen die Durchsicht der Quelltexte aufgebaut.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Reviews_als_Philosophie">Reviews als Philosophie</h2></div>

<p>Kontinuierliches Inspizieren des Quelltextes wie bei der <a href="Paarprogrammierung" title="Paarprogrammierung">Paarprogrammierung</a> ist auch eine der Methoden des <a href="Extreme_Programming" title="Extreme Programming">Extreme Programming</a>. Die im Extreme Programming (XP) eingesetzte Paarprogrammierung wird auch als „Codereview während der Entwicklung“ bezeichnet.

</p><p>Ein öffentliches Review ist ebenfalls eine Motivation der <a href="Open_Source" title="Open Source">Open-Source</a>-Software.

</p><p>Online-<a href="Repository" title="Repository">Software-Repositories</a> wie <a href="Github" class="mw-redirect" title="Github">Github</a>, <a href="GitLab" title="GitLab">GitLab</a> oder <a href="Bitbucket" title="Bitbucket">Bitbucket</a> erlauben es Gruppen von Individuen, gemeinschaftlich Codereviews durchzuführen und damit Sicherheit und Qualität des Programmcodes zu verbessern. Es lässt sich dabei beispielsweise festlegen, dass eine Mindestanzahl an Reviewern eine Änderung für gut befunden haben müssen, bevor es möglich ist diese Änderung in den restlichen Code zu integrieren.

</p><p>Darüber hinaus ist es auch möglich Problemstellen, die durch Werkzeuge für statische Codeanalyse im zu reviewenden Code erkannt wurden, entsprechend zu markieren, wodurch diese Probleme ebenfalls im Rahmen des Reviews behandelt werden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-Jones2002-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-Jones2002_1-0">a</a></sup> <sup><a href="#cite_ref-Jones2002_1-1">b</a></sup></span> <span class="reference-text"><span class="cite">Capers Jones, Chief Scientist Emeritus: <a rel="nofollow" class="external text" href="http://www.cs.nyu.edu/artg/Producing_Production_Quality_Software/Fall2005/lectures/SOFTWARE_QUALITY_IN_2002_CAPERS_JONES.pdf"><i>Software Quality in 2002: A Survey of the State of the Art.</i></a> (pdf; 234 kB) Software Productivity Research an Artemis company, 23. Juli 2002, <span style="white-space:nowrap;">S. 56</span>,<span class="Abrufdatum"> abgerufen am 15. Oktober 2013</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AReview+%28Softwaretest%29&rft.title=Software+Quality+in+2002%3A+A+Survey+of+the+State+of+the+Art&rft.description=Software+Quality+in+2002%3A+A+Survey+of+the+State+of+the+Art&rft.identifier=http%3A%2F%2Fwww.cs.nyu.edu%2Fartg%2FProducing_Production_Quality_Software%2FFall2005%2Flectures%2FSOFTWARE_QUALITY_IN_2002_CAPERS_JONES.pdf&rft.creator=Capers+Jones%2C+Chief+Scientist+Emeritus&rft.publisher=Software+Productivity+Research+an+Artemis+company&rft.date=2002-07-23&rft.language=en"> </span></span>

</li>

<li id="cite_note-CodeComplete-2"><span class="mw-cite-backlink"><a href="#cite_ref-CodeComplete_2-0">↑</a></span> <span class="reference-text">Steve McConnel: <cite style="font-style:italic">Code Complete</cite>. 2. Auflage. Microsoft, 2005, ISBN 978-3-86063-593-3, 21.3. Formal Inspections, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>530</span> (940 S.): „Individual inspections typically catch about 60% of defects, which is higher than other techniques except prototyping and high-volume beta testing“<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abookitem&rfr_id=info:sid/de.wikipedia.org:Review+%28Softwaretest%29&rft.atitle=21.3.+Formal+Inspections&rft.au=Steve+McConnel&rft.btitle=Code+Complete&rft.date=2005-01-27&rft.edition=2&rft.genre=bookitem&rft.isbn=9783860635933&rft.pages=530&rft.pub=Microsoft" style="display:none"> </span></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="http://standards.ieee.org/findstds/standard/1028-2008.html"><i>1028-2008 - IEEE Standard for Software Reviews and Audits.</i></a><span class="Abrufdatum"> Abgerufen am 2. Februar 2013</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AReview+%28Softwaretest%29&rft.title=1028-2008+-+IEEE+Standard+for+Software+Reviews+and+Audits&rft.description=1028-2008+-+IEEE+Standard+for+Software+Reviews+and+Audits&rft.identifier=http%3A%2F%2Fstandards.ieee.org%2Ffindstds%2Fstandard%2F1028-2008.html"> </span></span>

</li>

</ol>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>M.E. Fagan: <i><a rel="nofollow" class="external text" href="http://extras.springer.com/2002/978-3-642-59413-7/4/rom/pdf/Fagan_hist.pdf">Design and code inspections to reduce errors in program development.</a></i> IBM Systems Journal Vol. 15(3), 1976, S. 182–211.</li>

<li>Hansruedi Tremp: <i>IT-Systeme prüfen</i>. Compendio Verlag. 2. Auflage 2007. ISBN 978-3-7155-9304-3.</li>

<li>Peter Rösler, Maud Schlich, Ralf Kneuper: Reviews in der System- und Softwareentwicklung. Grundlagen, Praxis, kontinuierliche Verbesserung. dpunkt.Verlag, Heidelberg 2013, ISBN 978-3-86490-094-5.</li></ul></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2024-09-01" href="https://de.wikipedia.org/wiki/?title=Review_(Softwaretest)&oldid=248219849">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>